The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In client-server software applications, a server typically communicates with multiple clients. Frequently, there is a need to maintain information at the server that corresponds to each of the clients. For example, the server may maintain information defining the state of particular transactions with the clients. Furthermore, there is a need to maintain this information in such a manner that the server has access to the information for all of the clients, while each client only has access to the information associated with itself.
In object-oriented programming, design patterns are used to provide re-usable solutions to a recurring problem. Design patterns are described comprehensively in E. Gamma et al., “Design Patterns: Elements of Reusable Object-Oriented Software” (Reading, Mass.: Addison-Wesley, 1994), ISBN 0-201-63361-2.
A first approach to the client-server computing problem just described would be to use an object class, instantiated into objects at the server, which stores and represents client information. However, such a class would have no inherent limitations on the number of objects that may be instantiated from it. Accordingly, a program using such an approach could potentially instantiate more than one object instance per client. This could lead to storing inconsistent client-related information in different client objects.
Another approach to the problem just described uses programmatic objects that conform to the “singleton” design pattern of Gamma et al. The singleton design pattern ensures that an executing program has only one instance of any class. However, using the singleton pattern would result in instantiation of only one object instance for all of the clients in a client-server application. With only one object instance, it would be impossible to maintain information that corresponds to each of the clients. For example, if a server-side application program maintained a telephone number value in a singleton object, and one client modified its phone number value, then all of the other clients would be affected.
Based on the foregoing, there is a clear need for a better way to maintain information on behalf of multiple clients in a client-server application.
There is a specific need for a method in which each client only has access to the information associated with the respective client, but the server has access to the information associated with all of the clients, and yet the server cannot duplicate information associated with a particular client through multiple object instances.